.. :validated: 2.5.0

Создание дополнительных параметров групповых политик
------------------------------------------------------------------

Функционал групповых политик
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Групповые политики позволяют снизить стоимость управления ИТ-инфраструктурой за счет автоматического применения одинаковых настроек на больших группах компьютеров, имеющих общее целевое назначение.

Каждая политика (в терминах **MS AD** объект групповой политики) представляет из себя именованный набор параметров, в соответствии с которыми производится автоматическая настройка операционной системы и прикладного программного обеспечения.

Для создания и настройки групповой политики нужно выполнить следующие действия:

- создать новую групповую политику

- добавить конфигурационный параметр в политику (включить его)

- установить желаемые значения атрибутов для параметра

- назначить политику на подразделение, внутри которого есть целевые компьютеры или пользователи

- подождать от 30 минут до 80 минут или изменить таймер для получения и применения политики

Администраторам доступны сотни параметров «из коробки», которые соответствуют настройкам панели управления ОС **Astra Linux**. Но для решения частных задач конкретного бизнеса может потребоваться разработка дополнительных параметров силами команды внедрения, и в **ALD Pro** для этого есть все необходимые инструменты.

Версионность
^^^^^^^^^^^^

Каждая политика ГП имеет версию, которая автоматически изменяется, если наступило одно из следующих событий:

1. Внесены любые изменения в политики ГП или связанный с ней дополнительный параметр ГП. В этом случае дата изменений - это дата, когда пользователь внес изменения. А автор - это ФИО пользователя, внесшего изменения.

2. Произошло обновление версии **ALD Pro**. В этом случае дата изменений - это дата обновления системы. В этом случае "автором" изменений будет указано Системное обновление.

На основании параметра версионности standalone-minion принимает решение использовать при применении ГП сохраненные значения параметров, или запрашивать новые у службы каталогов.

Как работают групповые политики
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Для получения данных групповых политик и их применения используется pull-модель. Инициатором работы является миньон SaltStaсk (standalone-minion), установленный на каждом компьютере домена, который по протоколу LDAP к серверу службы каталогов получает актуальные данные о групповой политике.

Миньон Standalone — это рабочие станции или серверы, на которых работает демон-миньон Salt, обладающий широкой функциональностью, работающий автономно от мастера. Используется для запуска заданий в системе без подключения к мастеру.

.. important::
   
   Получение данных групповых политик и применение политик с помощью standalone-миньона реализовано с версии ALD Pro 2.2.0, ранее для этих задач использовался стандартный миньон SaltStack, который получал данные от мастера.

Подробнее о работе групповых политик указано в **Руководство Администратора. Часть 2 → Портал управления. Настройка и работа → Групповые политики → Групповые политики → Создание групповой политики** или в **Справочном центре** **ALD Pro**.

Как создать дополнительный параметр
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. list-table:: Привилегии для работы с дополнительными параметрами ГП
   :widths: 20 60 20
   :header-rows: 1
   :class: longtable

   * - Привилегия
     - Описание
     - На что распространяется
   * - Computer Group Policy Additional Parameters Catalog - Read
     - Привилегия позволяет:
       
       - Видеть список параметров компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров);
       
       - Видеть список папок компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров);
       
       - Видеть карточки параметров компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Параметр компьютеров>);
       
       - Видеть карточки папок параметров компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Папка параметров компьютеров>)
     - На весь домен
   * - User Group Policy Additional Parameters Catalog - Read
     - Привилегия позволяет:
       
       - Видеть список параметров пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры пользователей);
       
       - Видеть карточки параметров пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры пользователей/<Параметр пользователей>)
     - На весь домен
   * - Computer Group Policy Additional Parameters - Manage
     - Привилегия позволяет:
       
       - Создавать новые папки параметров компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров);
       
       - Изменять папки параметров компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Папка параметров компьютеров>);
       
       - Удалять папки параметров компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Папка параметров компьютеров>);
       
       - Создавать новые параметры компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров);
       
       - Изменять параметры компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Параметр компьютеров>);
       
       - Удалять параметры компьютеров (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Параметр компьютеров>)
     - На весь домен
   * - User Group Policy Additional Parameters - Manage
     - Привилегия позволяет:
       
       - Создавать новые папки параметров пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры пользователей);
       
       - Изменять папки параметров пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры пользователей/<Папка параметров пользователей>);
       
       - Удалять папки параметров пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры пользователей/<Папка параметров пользователей>);
       
       - Создавать новые параметры пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры пользователей);
       
       - Изменять параметры пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Параметр пользователей>);
       
       - Удалять параметры пользователей (Управление доменом/Доп. параметры групповых политик/вкладка Параметры компьютеров/<Параметр пользователей>)
     - На весь домен

Параметр групповой политики (в терминах **MS AD** шаблон групповой политики) подобен классу из теории объектно-ориентированного программирования. Он определяет модель для создания объектов конфигурирования, описывая их свойства (атрибуты) и методы для работы с этими данными (скрипт). Продолжая аналогию из ООП, «объектом» в данном случае будет являться экземпляр параметра, добавленный в конкретную групповую политику.

Параметр может быть «простым» или «составным»:

* В случае **простого** параметра свойства представляют из себя плоский список атрибутов. Например, для настройки межсетевого экрана может потребоваться задать уровень детализации журнала, и эта настройка подразумевает одно конкретное значение, поэтому она может быть реализована атрибутом «простого» параметра.

* **Составные** параметры позволяют задавать массив списка атрибутов, где в каждом списке представлен однотипный набор данных. Если продолжать пример с межсетевым экраном, то для настройки фильтрации может потребоваться разрешить входящие ssh-соединения, запретить исходящие smtp и т.п., поэтому такие настройки нужно реализовывать атрибутами «составного» параметра.

Параметр может быть «параметром компьютера» или «параметром пользователя». «Параметры компьютеров» отвечают за настройку оборудования и служб вне зависимости от того, какой пользователь работает с системой. «Параметры пользователей» отвечают за настройку рабочей среды пользователя вне зависимости от того, на каком компьютере он работает. В обоих случаях скрипты выполняются с возможностями по администрированию root-пользователя.

Чтобы создать новый параметр групповой политики нужно перейти на страницу **Управление доменом** → **Доп. параметры групповых политик** и выбрать одну из вкладок:

.. figure:: media/group_policies_1.png
   :name: group_policies_1.png

   Как создать дополнительный параметр 1

.. figure:: media/group_policies_2.png
   :name: group_policies_2.png

   Как создать дополнительный параметр 2

На каждой вкладке по умолчанию будет представлен корневой **Каталог дополнительных параметров**, внутри которого вы можете создавать свои пользовательские параметры. Если параметров станет слишком много, вы сможете группировать их по подразделам.

Выберите раздел **Каталог дополнительных параметров**, нажмите кнопку **[+ Новый параметр]** и заполните карточку следующими значениями:

**Раздел «Основные»**

* Название параметра: «Диспетчер задач htop». Это название, которое будет отображаться в каталоге при редактировании групповых политик на портале управления.

* Уникальный идентификатор: «software_htop». Это название, которое будет использоваться в качестве имени ``\*.sls`` файла на диске и в скриптах SaltStack. Формируется по следующей формуле: ``rbta_ldap_custom_gp_host_`` + введенные пользователем данные "software_htop". Для пользователей ``rbta_ldap_custom_gp_user_``.

* Тип каталога: «Параметр компьютерной групповой политики». Определяет, относится ли данный параметр к настройкам компьютера или пользователя. Параметр не доступен для редактирования, его значение определяется автоматически в зависимости от того, с какой страницы вы перешли к созданию дополнительного параметра.

* Тип параметра: «простой». Определяет вид параметра. **Простой** - простой список атрибутов, **Составной** - массив списка атрибутов.

* Папка параметра: «Дополнительные параметры». Указывает раздел каталога, в котором будет доступен данный параметр.

* Назначение параметра: «Управление установкой и настройкой диспетчера задач htop». Текстовое описание, позволяющее указать наиболее важную информацию о работе параметра для удобства последующего использования. Данный текст отображается при редактировании групповой политики по нажатию кнопки вопроса. Здесь же можно внести данные о требованиях к ОС (см. **Руководство Администратора. Часть 1** -- **Общие сведения** -- **Планирование ресурсов**).

* Разделы **Атрибуты параметра** и **Конфигурация скрипта** станут доступны при редактировании сохраненного параметра.

Особенности редактирования дополнительных параметров ГП
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Для редактирования дополнительного параметра групповых политик нужно перейти на страницу **Управление доменом** → **Доп. параметры групповых политик** → **Параметры компьютеров** или **Параметры пользователей** → **“Имя параметра”** и внести нужные изменения, сохранить.

Чтобы эти параметры синхронизировались с групповыми политиками и применились на компьютерах и пользователях нужно перейти на карточку этих политик **Групповые политики** → **Групповые политики** → **“Имя политики”**, внести изменения и сохранить. Изменения в групповой политике приведут к повышению ее версии. Только после этого изменения дополнительных параметров ГП будут применены на компьютерах и для пользователей. Или принудительно применить политику (подробнее читайте в :ref:`ref_dbg`).

Аналогичные действия необходимо применить если дополнительный параметр групповой политики был удален.

Как настроить атрибуты дополнительного параметра
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

**Атрибуты** — это свойства, которые можно задавать при добавлении параметра к групповой политике. Например, если мы создадим параметр для управления диспетчером задач ``htop`` на рабочих станциях, то нам понадобится атрибут «Должен быть установлен», чтобы в зависимости от его значения устанавливать или удалять указанное программное обеспечение.

.. figure:: media/group_policies_3.png
   :name: group_policies_3.png

   Как настроить атрибуты дополнительного параметра

Атрибуты представляют из себя обычные текстовые строки, значение которых может быть интерпретировано в скриптах в том числе как числа, логические значения ($true и $false), списки и т.п. Добавьте атрибут:

* Название атрибута: «Должен быть установлен»

*Название, под которым будут видеть этот атрибут на карточке параметра.*

* Уникальный идентификатор: «must_be_installed»

*Идентификатор атрибута, который будет использоваться как имя переменной в SaltStack скриптах.*

* Описание: «атрибут используется как логическая переменная true / false для ветвления шаблона»

*Краткие комментарии для инженера, которые помогут упростить поддержку этого атрибута в будущем, когда потребуется внести какие-либо изменения. Данная информация недоступна при настройке групповой политики, поэтому, если вы хотите дать подсказку администратору о возможных значениях этого атрибута, внесите эту информацию в описание параметра.*

* Обязательный: ``true``

*Пользователь должен указать значение атрибута*

* Уникальный: ``true``

Применяется для составных параметров, у которых возможны конфликты. Для разрешения конфликтов для каждого параметра нужно определить уникальный атрибут. В рамках одного ГПО нельзя будет создать массив списка атрибутов с одинаковыми значениями уникального параметра.

Скрипт дополнительного параметра
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Скрипты SaltStack похожи на PHP, в них текст перемежается императивными инструкциями языка программирования, по результату выполнения которых получается итоговый документ. За императивную часть отвечают инструкции шаблонизатора Jinja2, а декларативная часть задается по правилам SaltStack в YAML-подобном синтаксисе.

Императивные инструкции шаблонизатора Jinja
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Инструкции языка Jinja внедряются с помощью фигурных скобок:

- ``{% … %}`` - синтаксис для вставки инструкции языка шаблонизатора Jinja. Аналог PHP: ``<? … ?>``
- ``{% print(…) %}`` - пример инструкции для вывода в документ по месту вызова значения выражения. Аналог PHP: ``<? echo (…) ?>``
- ``{{ … }}`` - краткий синтаксис для вывода в документ по месту вызова значения выражения. Аналог PHP: ``<?= … ?>``
- ``{### … #}`` - синтаксис для вставки комментариев средствами языка Jinja2. Аналог PHP: ``<?/* … */?>``

Для повышения читабельности кода управляющие структуры обычно оформляют отступами, но yaml-документы крайне чувствительны к пробелам, поэтому данный инструмент форматирования оказывается недоступен без применения специальных операторов подавления отступов. Чтобы убрать лишние пробелы и пустые строки вам нужно всего лишь поставить знак дефиса слева, справа или с обоих концов управляющего блока:

- ``{%-`` - удаляет пробелы и пустые строки слева;
- ``-%}`` - удаляет перенос текущей строки и переносит ее на предыдущую;
- ``{%-`` и ``-%}`` - удаляет пробелы и пустые строки слева, в т.ч. перенос текущей строки, поэтому текст окажется в конце предыдущей строки.

.. attention::

   При сохранении скрипта может появится предупреждение: "Ошибка конфигурации скрипта. Игнорировать ошибку и сохранить изменения?". Встроенный механизм проверяет соответствие указного скрипта формальным правилам, поэтому если есть уверенность, что скрипт корректный необходимо выбирать "Да" для сохранения.

Выполнение команд
'''''''''''''''''

Создайте файл ``hello.sls`` с простейшим Jinja-скриптом, чтобы проверить, как это работает, и выполните его с помощью команды ``aldpro-salt-call`` с указанными параметрами:

.. code-block:: bash

   echo '{% do salt.log.info("Hello world!") %}' > hello.sls
   
   aldpro-salt-call --local --file-root = . state.sls hello

Несколько комментариев:

* Оператор «do» вызывает метод ``salt.log.info`` с параметром 'Hello world!'
* Команда ``aldpro-salt-call`` отвечает за локальное исполнение скриптов на миньонах.
* Параметр ``local`` исключает обращение к мастеру для получения настроек.
* Параметр ``file-root`` со значением «.» устанавливает в качестве рабочего каталога текущую директорию.
* Параметр ``state.sls`` указывает на то, что следует использовать метод sls модуля ``salt.modules.state``, который применяет состояния, описанные в одном и более файлов на диске из рабочей директории.
* Параметр ``hello`` задает имя файла ``hello.sls``, которое должно быть указано без расширения файла.

Еще один пример. С помощью метода run модуля cmd можно выполнить на удаленном хосте любую команду ``bash``:

.. code-block:: bash

   echo '{% do salt.cmd.run("apt-get install htop") %}' > installhtop.sls

   aldpro-salt-call --local --file-root = . state.sls installhtop

Полный перечень всех модулей SaltStack можно найти на странице документации:
https://docs.saltproject.io/en/latest/ref/modules/all/index.html

Работа с переменными
''''''''''''''''''''

Переменные на языке Jinja задаются оператором ``set``. Вам доступен широкий перечень типов данных: булевые, числовые, текстовые, списки, кортежи, словари:

.. code-block:: jinja

   {% set boolean_val = True %}
   {% set int_val = 777 %}
   {% set string_val = 'hello' %}
   {% set list_val = ['h', 'e', 'l', 'l', 'o'] %}
   {% set tuple_val = ('h', 'e', 'l', 'l', 'o') %}
   {% set dict_val = { b: True, i: 777, s: 'hello') %}

При работе с числовыми переменными доступны обычные математические операторы:

.. code-block:: jinja

   {% set a = 5 %}
   {% set b = 10 %}
   {% set a = a + b %}
   {% set b = a - b %}
   {% set a = a - b %}

Конкатенация строк возможна как специальным оператором «~», который предварительно конвертирует все значения в строки, так и обычным оператором сложения «+»:

.. code-block:: jinja

   {% set a = 5 %}
   {% set b = 10 %}
   {% set c = a ~ b %}
   {% set d = 'World' %}
   {% set e = 'Hello, ' + d %}

Для выполнения более сложных преобразований над переменными доступно множество функций, которые можно применять как методы через точку или в стиле конвейеров ``bash`` через символ вертикальной черты, за что их так же называют фильтрами:

.. code-block:: jinja

   {% set a = 'Hello'.upper() %}
   {% set b = 'world' | upper %}

Полный перечень встроенных фильтров Jinja можно найти в документации:
https://jinja.palletsprojects.com/en/2.11.x/templates/#list-of-builtin-filters

Ветвления и циклы
'''''''''''''''''

Если выполнение набора команд должно зависеть от некоторого условия, то ветвление можно задать с помощью операторов if/elseif/else/endif:

.. code-block:: jinja

   {% if ram >= 2048 %}
   ...
   {% elseif ram <= 4096 %}
   ...
   {% else %}
   ...
   {% endif %}

Циклы for являются аналогом конструкций типа foreach других языков программирования и предназначены для выполнения заданного набора инструкций применительно к каждому элементу из списка:

.. code-block:: jinja

   {% set users = ['ivanov', 'petrov', 'kuznetsov'] %}
   {% for user in users %}
   {% do salt.log.info(user.upper()) %}
   {% endfor %}

Если нужно обработать данные словаря, используется метод items(), чтобы получить список его элементов:

.. code-block:: jinja

   {% set users = {'u1':'ivanov', 'u2':'petrov', 'u3':'kuznetsov'} %}
   {% for id, user in users.items() %}
   {% do salt.log.info(user.upper()) %}
   {% endfor %}

Так как циклы Jinja работают только со списками, то для эмуляции обычных циклов со счетчиком вам нужно воспользоваться функцией range([min], max). Если передать этой функции один параметр, то будет сгенерирован список с указанным количеством элементов, нумерация которых будет начинаться с нуля. Если передать два числа, то нумерация элементов будет в указанном диапазоне:

.. code-block:: jinja

   {% do salt.log.info('Обратный отсчет') %}
   {% for i in range(0, 10) %}
   {% do salt.log.info(10 - i) %}
   {% endfor %}

Информация о целевой системе (grains)
'''''''''''''''''''''''''''''''''''''

При написании скриптов Jinja можно опираться на информацию о целевом хосте, на котором этот скрипт будет применен. Данная информация доступна в словаре grains, тут находится информация об операционной системе, памяти, дисках, настройках сетевых интерфейсов и многом другом. Например, используя ключ nodename можно получить имя хоста:

.. code-block:: jinja

   {% set node = salt['grains.get']('nodename') %}

Актуальное содержание словаря ``grains`` для конкретного хоста можно посмотреть с миньона утилитой ``aldpro-salt-call``:

.. code-block:: console

   aldpro-salt-call grains.items
   local:
        ----------
        astra_version:
        ----------
       distr:
           orel
       version:
           1.7.2
       ...

Более подробную информацию о модулях grains можно найти в документации по проекту:
https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.grains.html

Передача информации с мастера (pillar)
''''''''''''''''''''''''''''''''''''''

При настройке групповых политик администраторы задают значения атрибутов, которые доменным компьютерам передаются через механизм пилларов (``salt pillar``, соляной столб). Актуальное содержание словаря ``pillar`` можно посмотреть с миньона утилитой ``aldpro-salt-call``.

Для компьютеров:

.. code-block:: bash

   aldpro-salt-call pillar.get aldpro-hosts:pc-1.ald.company.lan

Для пользователей:

.. code-block:: bash

   aldpro-salt-call pillar.get aldpro-users:<логин пользователя> 

Содержание словаря определяется тем, какие политики назначены конкретному компьютеру (условный аналог GPResult в **MS AD**). Данные пиллара доступны только тем миньонам, для кого они предназначены, поэтому через атрибуты можно передавать в том числе конфиденциальную информацию, например пароли служебных учетных записей, сертификаты.

Если же нужно проверить, была ли уже применена конкретная политика на хосте, можно применить состояние с параметром test=True. Если по результатам выполнения команды появится сообщение “No changes needed to be made”, значит система уже получила pillar с заданной групповой политикой:

.. code-block:: console

   aldpro-salt-call state.apply rbta_ldap_env_vars_h test=True
   ...
            ID: /etc/bash.bashrc
       Function: file.blockreplace
         Result: True
        Comment: No changes needed to be made
   ...

Более подробную информацию о модулях pillar можно найти в документации по проекту:
https://docs.saltproject.io/en/latest/topics/tutorials/pillar.html

Создание файлов на стороне миньона
''''''''''''''''''''''''''''''''''

Есть методы для создания файлов ``touch``, переименования ``rename``, удаления ``clean``. Подробное описание возможностей доступно на странице:

- https://docs.saltproject.io/en/latest/ref/states/all/salt.states.file.html

- https://www.8host.com/blog/osnovy-saltstack-bazovye-terminy-i-ponyatiya/

- https://serverspace.ru/support/help/ispolzovanie-platformy-salt/

Декларативные описания SaltStack
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Декларативная часть скрипта описывает в YAML-формате желаемую конфигурацию компьютера. В структуре документа указано, какие методы нужно вызывать для конфигурирования системы, и с какими параметрами. В качестве примера создадим файл ``software.sls`` со скриптом, который описывает состояние, после применения которого в системе должен стать доступен диспетчер задач ``htop``:

.. code-block:: console

   cat software.sls
   software_htop: ### Имя состояния
   ··pkg.installed: ### Вызов метода installed модуля pkg
   ····-·pkgs: ### Аргументы метода installed
   ······-·htop ### Значение аргумента pkgs

Можно выполнить скрипт с помощью команды:

.. code-block:: bash

   aldpro-salt-call --local --file-root = . state.sls software

Подробное рассмотрение параметров команды:

* ``local`` — означает локальную обработку без обращения к мастеру;
* ``file-root=.`` — устанавливает рабочую директорию, в которой будет выполняться поиск \*.sls файлов;
* ``state.sls`` — указывает, что следует использовать модуль sls, который отвечает за применение состояний из файлов на диске;
* ``software`` — указывает имя \*.sls файла без расширения.

Язык ``YAML``, также как и ``JSON``, является языком разметки текста для сериализации данных. Каждая строка задает пару ключ-значение, между которыми стоит знак двоеточия. Ключи могут состоять из одного и более слов, причем, заключать их в кавычки необязательно. В качестве значений поддерживаются как скалярные типы данных (``int, float, boolean, string``), так и вложенные словари, что позволяет создавать древовидные структуры данных. Второй и последующий уровни дерева должны обозначаться отступами с помощью двух и более пробелов, использовать символы табуляции вместо пробелов недопустимо. Если требуется прокомментировать какой-то фрагмент  документа, то слева от комментария нужно поставить символ решетки.

На верхнем уровне структуры данных должен быть указан ключ с именем состояния, например, ``software_htop``. Имя выбирается произвольно, в одном документе может быть описано несколько состояний, но их имена не должны повторяться.

На второй строке указано, что требуется вызвать метод ``installed`` модуля ``salt.states.pkg``. Данный модуль является модулем состояния, т. е. его методы приводят систему к требуемому состоянию, описывая желаемый конечный результат, а не то, как к нему прийти. Есть также модули исполнения, которые выполняют в системе конкретные действия, ранее был приведен пример с использованием метода run модуля cmd для выполнения ``bash`` команды.

На третьей и четвертой строке методу передается аргумент ``pkgs`` со значением ``htop``. Важно обратить внимание, что аргумент и его значение являются элементами списков, поэтому в начале этих строк стоит символ дефиса.

.. _ref_dbg:

Отладка
~~~~~~~

Скрипт дополнительного параметра сохраняется в сервере службы каталогов ``({корень} → cn=etc → cn=aldpro → cn=vcsStorage → cn=grouppolicy → cn={Идентификатор ГП})`` и при получении по протоколу LDAP кешируется на миньоне в папках вместе с остальными групповыми политиками:

* Параметры компьютеров: ``/srv/aldpro-salt/roots/states/policies/host-policies/``
* Параметры пользователей: ``/srv/aldpro-salt/roots/states/policies/user-policies/``

В соответствии с расписанием из файла ``/srv/aldpro-salt/roots/_modules/utils.py`` скрипты выполняются при запуске службы ``aldpro-salt-minion`` и по расписанию каждые 30 минут + от 5 до 50 минут случайного времени. Другими словами политики гарантировано применятся в течение 80 минут. Посмотреть текущее значение таймера можно командой:

.. code-block:: bash

   aldpro-salt-call schedule.show_next_fire_time build_gp_pillars

При необходимости можно локально изменить время стационарного таймера (по умолчанию 30 минут):

1. В файле на клиентском компьютере: ``/srv/aldpro-salt/config/minion.d/standalone_scheduler.con`` изменить значение атрибута ``seconds/minutes`` в блоке интересующего задания. Для групповых политик это ``build_gp_pillars``.
2. В файле ``/srv/aldpro-salt/_modules/utils.py`` заменить ``_25_MINUTES = dt.timedelta(minutes=25)``. Выставлять значения таймера менее 10 минут нежелательно, это может привести к  повышению нагрузки и на контроллер домена и на доменный компьютер. 
3. Перезапускаем миньон командой:

.. code-block:: bash

   systemctl restart aldpro-salt-minion.service

Другой способ применения групповых политик: можно на миньоне вручную ввести команду (аналог ``gpupdate /force``):

.. code-block:: bash

   aldpro-salt-call state.apply gpupdate.gp

Можно в конце команды добавить ``pillar='{“force”: True}'`` - принудительное  удаление связанного с политикой кэша. ``pillar='{“verbose”: True}'`` нужен для получения логов выполнения заданий применения. Использовать рекомендуется осторожно, поскольку вызывает повышенную нагрузку на контроллер домена.

Применить отдельно политики пользователя можно командой:

.. code-block:: bash

   aldpro-salt-call state.apply policies.user-policies  pillar="{'user': 'username'}"

Для работы с политиками пользователей нужно явно передавать имя пользователя, чьи настройки вы хотите применить ``pillar=“{'user': 'username'}”``.

Требования к скриптам и наследование параметров
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

С 2.2.0 архитектура **ALD Pro** в части работы групповых политик изменилась, скрипты групповых политик получают только те компьютеры и пользователи, которым назначена политика. В связи с этим в скрипте может не быть проверки на назначение параметра конкретному компьютеру или пользователю.

Если на один компьютер или пользователя назначено несколько политик, использующих один и тот же параметр, то значения простых параметров будут переопределяться, а значения составных параметров суммироваться (см. **Полезные инструкции** → **Наследования и суммирование групповых политик**).

Миньон получает политики, назначенные на компьютер или авторизованного на компьютере пользователя. **ALD Pro** анализирует назначенные параметры, снизу вверх по дереву подразделений, оставляя только те которые соответствуют требованиям к операционной системе. Из оставшихся в результате операций суммирования и наследования формирует единый словарь ``pillar``. Скрипты групповых политик отрабатываются миньоном только один раз с итоговым содержанием словаря ``pillar``, вне зависимости от того, сколько раз соответствующий параметр был использован в объектах групповых политик, назначенных на этот компьютер или пользователя.